home *** CD-ROM | disk | FTP | other *** search
/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.438 < prev    next >
Text File  |  1996-02-12  |  28KB  |  667 lines

  1. Frequently Asked Questions (FAQS);faqs.438
  2.  
  3.  
  4.  
  5. xwindows/xshowgif:
  6. README.1st          ;Installation notes for xshowgif
  7. xshowgif.tar.Z      ;Compressed tar file for xshowgif
  8.  
  9. xwindows/xv:
  10. README.1st          ;Installation notes for xv v. 2.00
  11. xv2.tar.Z           ;Compressed tarfile for xv v. 2.00
  12.  
  13. xwindows/xviewgl:
  14. README.1st          ;Installation notes for xviewgl
  15. xviewgl_v1.0.tar.Z  ;Compressed tar file for xviewgl
  16. -------------------------------------------------------------------------------
  17.  
  18. That's about it for this introduction.  If you have any suggestions
  19. for things to include in future versions, don't hesitate to let me
  20. know...
  21.  
  22.          ~ deej ~              | (If I were expressing Cadence's opinions, )
  23. Jim Howard -- deej@cadence.com | (they'd probably make me wear a tie...    )
  24.         (^:=             Flames cheerfully ignored.             =:^)
  25. "I tell you this:  no eternal reward will forgive us now
  26.  for wasting the dawn" -- Jim Morrison, The Doors
  27. Xref: bloom-picayune.mit.edu news.misc:8888 news.answers:3056
  28. Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!spool.mu.edu!news.cs.indiana.edu!purdue!spaf
  29. From: spaf@cs.purdue.EDU (Gene Spafford)
  30. Newsgroups: news.misc,news.answers
  31. Subject: Changes to Rules for posting to Usenet
  32. Message-ID: <spaf-c_rules_716962672@cs.purdue.edu>
  33. Date: 20 Sep 92 04:17:52 GMT
  34. Expires: 19 Nov 92 16:17:52 GMT
  35. Followup-To: news.misc
  36. Organization: Dept. of Computer Sciences, Purdue Univ.
  37. Lines: 29
  38. Approved: spaf@cs.purdue.EDU
  39. Supersedes: <spaf-c_rules_711614966@cs.purdue.edu>
  40.  
  41. Archive-name: posting-rules/diff1
  42. Last-change: 3 Sep 1992 by dan_jacobson@att.com (Dan Jacobson)
  43.  
  44.  
  45. *** old/rules.n    Mon Jul 20 01:49:28 1992
  46. --- ./src/rules.n    Thu Sep  3 21:31:31 1992
  47. ***************
  48. *** 5,7 ****
  49.   Original-author: mark@stargate.com (Mark Horton)
  50. ! Last-change: 11 May 1992 by barmar@Think.COM (Barry Margolin)
  51.  
  52. --- 5,7 ----
  53.   Original-author: mark@stargate.com (Mark Horton)
  54. ! Last-change: 3 Sep 1992 by dan_jacobson@att.com (Dan Jacobson)
  55.  
  56. ***************
  57. *** 199,201 ****
  58.   question that's answered there, you'll likely receive a number of
  59. ! responses that scream "RTFM" (Read the F* Manual).
  60.  
  61. --- 199,201 ----
  62.   question that's answered there, you'll likely receive a number of
  63. ! responses that scream "RTFM" (Read the F*ing Manual).
  64.  
  65. --
  66. Gene Spafford
  67. Software Engineering Research Center & Dept. of Computer Sciences
  68. Purdue University, W. Lafayette IN 47907-1398
  69. Internet:  spaf@cs.purdue.edu    phone:  (317) 494-7825
  70. Xref: bloom-picayune.mit.edu news.announce.newusers:914 news.answers:3558
  71. Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!mojo.eng.umd.edu!darwin.sura.net!wupost!cs.utexas.edu!sun-barr!ames!purdue!spaf
  72. From: spaf@cs.purdue.EDU (Gene Spafford)
  73. Newsgroups: news.announce.newusers,news.answers
  74. Subject: Rules for posting to Usenet
  75. Message-ID: <spaf-rules_719471658@cs.purdue.edu>
  76. Date: 19 Oct 92 05:14:19 GMT
  77. Expires: 18 Dec 92 17:14:18 GMT
  78. Followup-To: news.newusers.questions
  79. Organization: Dept. of Computer Sciences, Purdue Univ.
  80. Lines: 255
  81. Approved: spaf@cs.purdue.EDU
  82. Supersedes: <spaf-rules_716962643@cs.purdue.edu>
  83.  
  84. Archive-name: posting-rules/part1
  85. Original-author: mark@stargate.com (Mark Horton)
  86. Last-change: 3 Sep 1992 by dan_jacobson@att.com (Dan Jacobson)
  87.  
  88. This message describes some of the rules of conduct on Usenet.  The rules
  89. vary depending on the newsgroup.
  90.  
  91.  
  92. Some newsgroups are intended for discussions and some for announcements
  93. or queries.  It is not usually a good idea to carry on discussions in
  94. newsgroups that are designated otherwise.  It is never a good idea to
  95. carry on "meta-discussions" about whether a given discussion is
  96. appropriate -- such traffic mushrooms until nobody can find articles
  97. that belong.  If you are unhappy with what some user said, send him/her
  98. mail, don't post it.
  99.  
  100.  
  101. Before posting, think about where your article is going.  If it's
  102. posted to a "comp", "news", "misc", "soc", "sci", "rec" or "talk"
  103. newsgroup, it will probably go to the USA, Canada, Europe, Australia,
  104. and many countries in Asia.  Certain articles are only of local
  105. interest (e.g. used car ads) and it is inappropriate to post them to
  106. the whole world.  Use the "Distribution" feature to restrict
  107. distribution to your local area.  If you don't know how to use this
  108. feature, read "Frequently Submitted Items" in another article in
  109. news.announce.newusers. (Note, however, that some sites have broken
  110. software or improperly configured news systems, so sometimes use of a
  111. "Distribution" header may not work.)
  112.  
  113.  
  114. Be considerate with your use of network resources.  Your individual
  115. usage may not seem like much compared to the net as a whole, but in
  116. aggregate, small savings in disk or CPU add up to a great deal.  For
  117. instance, messages offering thanks, jibes, or congratulations will
  118. only need to be seen by the interested parties -- send these by mail
  119. rather than posting them. The same goes for simple questions, and
  120. especially for any form of "me too" posting.
  121.  
  122. To help minimize some transfer load and disk usage throughout the
  123. Usenet, consider not only how many groups should carry your posting
  124. over what distribution area, but also how long it will be useful. Many
  125. kinds of postings -- such as those making announcements or offers --
  126. have a obvious useful lifetime. Posted questions that aren't answered
  127. within a decent interval probably won't be answered at all, and
  128. announcements will have a limited lifetime. All such postings will be
  129. using bandwidth to no purpose after a certain time.  When making such
  130. postings one should determine what that time interval is, based upon
  131. the nature of the posting, the volume of articles on the newsgroup(s)
  132. involved, and the habits of the audience, if known. Then include an
  133. expiration date in the posting. This will mark the date after which
  134. the article should not be retained at each site.
  135.  
  136. To include an expiration date in an article, when posting insert a
  137. line in the header below the "Newsgroups:" line with the expiration.
  138. For instance, type "Expires: 5 Feb 92" to have the article expire
  139. after Feb 5, 1992.  Most news software will also accept expiration
  140. dates of the form "Expires: +5days".  Please do NOT set expiration
  141. dates far into the future simply to have the article stay around.
  142. Many sites expire old articles no matter what the header indicates, so
  143. you are unlikely to achieve much other than clutter the disk on a few
  144. sites.  Default expiration is normally in the range of 7 to 21 days,
  145. depending on disk space at each site.
  146.  
  147.  
  148. Don't post announcements regarding major news events (e.g. the space
  149. shuttle has just exploded!) to news groups.  By the time most people
  150. receive such items, they will long since have been informed by
  151. conventional media.  If you wish to discuss such an event on the net,
  152. use the "misc.headlines" newsgroup.
  153.  
  154.  
  155. Announcement of professional products or services on Usenet is allowed;
  156. however, since someone else is paying the phone bills for this, it is
  157. important that it be of overall benefit to Usenet.  Post to the
  158. appropriate newsgroup -- comp.newprod -- never to a general purpose
  159. newsgroup such as "misc.misc".  Clearly mark your article as a product
  160. announcement in the subject.  Never repeat these -- one article per
  161. product at the most; preferably group everything into one article.
  162. Advertising hype is especially frowned upon -- stick to technical
  163. facts.  Obnoxious or inappropriate announcements or articles violating
  164. this policy will generally be rejected.  This policy is, of course,
  165. subject to change if it becomes a problem.
  166.  
  167.  
  168. Some newsgroups are moderated.  In these groups, you cannot post
  169. directly, either by convention or because the software prevents it.  To
  170. post to these newsgroups, send mail to the moderator. Examples:
  171.  
  172. Newsgroup        Moderator    Purpose
  173. ---------        ---------    -------
  174. news.announce.important stargate!announce    Important announcements for everyone
  175. comp.std.unix        uunet!std-unix    Unix standards discussion
  176. comp.std.mumps        plus5!std-mumps    ANSI Mumps standards discussion
  177. comp.unix        zorba!modunix    Discussion of Unix* features and bugs
  178.  
  179. Some newsgroups have special purpose rules:
  180.  
  181. Newsgroup        Rules
  182. ---------        -----
  183. news.announce.important    Moderated, no direct postings, important things only.
  184. misc.wanted        Queries, "I want an x", "Anyone want my x?".  No
  185.             discussions. Don't post to more than one xxx.wanted.
  186.             Use the smallest appropriate wanted (e.g. used car
  187.             ads to nj.wanted.)
  188.             Requests for sources, termcaps, etc. should go to the
  189.             "comp.sources.wanted" newsgroup.
  190. rec.humor        Clean humor only; anything offensive must be rotated;
  191.             no discussions -- humor only.  Discussions go in
  192.             rec.humor.d
  193. rec.arts.movies        Don't post anything revealing part of a movie
  194.             without marking it (spoiler) in the subject.
  195. rec.arts.*        Same as movies -- mark spoilers in the subject line.
  196. news.groups        Discussions about new groups: whether to create
  197.             them and what to call them.  Don't post yes/no
  198.             votes, mail them to the author
  199. misc.test        Use the smallest test group possible, e.g.
  200.             "test" or "ucb.test".  Say in the body of the
  201.             message what you are testing.
  202.  
  203.  
  204. It is perfectly legal to reproduce short extracts of a copyrighted work
  205. for critical purposes, but reproduction in whole is strictly and
  206. explicitly forbidden by US and international copyright law.  (Otherwise,
  207. there would be no way for the artist to make money, and there would
  208. thus be less motive for people to go to the trouble of making their art
  209. available at all.  The crime of theft is as serious in this context as
  210. any other, even though you may not have to pick locks, mask your face,
  211. or conceal merchandise.)
  212.  
  213. It is generally considered rude to post private e-mail correspondence
  214. without the permission of the author of that mail.  Furthermore, under
  215. copyright statutes, the author of the e-mail possesses a copyright on
  216. mail that he or she wrote; posting it to the net or mailing it on to
  217. others without permission of the author is likely a violation of that
  218. copyright as well as being rude.
  219.  
  220. All opinions or statements made in messages posted to Usenet should be
  221. taken as the opinions of the person who wrote the message.  They do not
  222. necessarily represent the opinions of the employer of that person, the
  223. owner of the computer from which the message was posted, or anyone
  224. involved with Usenet or the underlying networks of which Usenet is made
  225. up.  All responsibility for statements made in Usenet messages rests
  226. with the individual posting the message.
  227.  
  228.  
  229. Posting of information on Usenet is to be viewed as similar to
  230. publication.  Because of this, do not post instructions for how to do
  231. some illegal act (such as jamming radar or obtaining cable TV service
  232. illegally); also do not ask how to do illegal acts by posting to the
  233. net.
  234.  
  235.  
  236. If you have a standard signature you like to append to your articles,
  237. put it in a file called .signature in your home directory.  "postnews"
  238. and "inews" will automatically append it to your article.  Please keep
  239. your signatures concise, as people do not appreciate seeing lengthy
  240. signatures, nor paying the phone bills to repeatedly transmit them.  2
  241. or 3 lines are usually plenty.  Sometimes it is also appropriate to add
  242. another line or two for addresses on other major networks where you can
  243. be reached (e.g., Internet, Bitnet).  Long signatures are
  244. definitely frowned upon.  DO NOT include drawings, pictures, maps, or
  245. other graphics in your signature -- it is not the appropriate place
  246. for such material and is viewed as rude by other readers.
  247.  
  248.  
  249. If you post an article and remember something you've left out or
  250. realize you've made a factual error, you can cancel the article and (if
  251. canceled quickly enough) prevent its distribution.  Then you can
  252. correct whatever was wrong and post a new copy.  In "rn" and
  253. "readnews", an article that you posted can be canceled with the "C"
  254. command.  Be aware, however, that some people may have already read the
  255. incorrect version so the sooner you cancel something, the better.
  256.  
  257.  
  258. Before posting a question to the net (especially one that you think
  259. will be easy for experts to answer), consider carefully whether
  260. posting is the most appropriate way to get the answer.  There are many
  261. ways to find answers without using up network resources and forcing
  262. thousands of people to read your question (and several helpful
  263. volunteers to spend time responding).  Many newsgroups have a
  264. Frequently Asked Questions (FAQ) list that is posted periodically
  265. (usually about once a month), and they are also usually cross-posted
  266. to news.answers.  They usually have explicit expiration dates set, so
  267. they shouldn't be expired until a new version has been posted, so if
  268. you can't find the FAQ in either the newsgroup or news.answers, there
  269. probably isn't one (thus, it's probably not useful to post a question
  270. asking whether there is one).  If you have local experts (or simply
  271. more experienced users than yourself) at your site, try asking them
  272. before posting.  If you're trying to find where you can FTP software
  273. or a newsgroup archive, try using the Archie service; see postings in
  274. news.answers for details.  Many newsgroups are also archived in Wide
  275. Area Information Service (WAIS) databases; WAIS client software may be
  276. FTPed from ftp.think.com, or you may use WAIS by telnetting to
  277. quake.think.com and logging in as "wais".  Finally, you should also
  278. check the manuals for your system; if you don't, and you post a
  279. question that's answered there, you'll likely receive a number of
  280. responses that scream "RTFM" (Read the F*ing Manual).
  281.  
  282.  
  283. If the news system rejects a followup due to "more quoted lines than
  284. new text," please do not use "filler" lines to make up for this.
  285. Instead, if after careful editing, you have more to quote than to
  286. write, change the citation character.  For example, in the display
  287. editor vi, you could use the incantation:
  288.     :%s/^>/</
  289. Be careful not to do the very similar:
  290.     :%s/>/</
  291. which will affect >'s that are not being used as the citation
  292. character.  (In particular, it will damage the "References" line in the
  293. article header.)
  294.  
  295.  
  296. In preparing an article, be aware that other people's machines are
  297. not the same as yours.  The following is a list of things to keep
  298. in mind:
  299.  * Except for source, keep your lines under 80 characters, and
  300.    under 72 if possible.  (most editors have a fill or format
  301.    mode that will do this for you automatically)
  302.  * Right justified text may look "prettier" in some sense, but it
  303.    is almost always harder to read than leaving ragged right
  304.    margins; don't justify your articles.
  305.  * Most special control characters will not work for most readers.
  306.    In fact, the  space character is about the only one
  307.    you can be sure will work consistently. Even tabs aren't always
  308.    the same from machine to machine, and should be avoided.  Many mail
  309.    agents will strip or remap control characters.
  310.  * Pictures and diagrams should not use embedded tabs.
  311.  * Refer to articles by Message-ID, and never by article number.
  312.  * What you think is the previous article is unlikely to be so elsewhere.
  313.  * Submissions in a single case (all upper or all lower) are
  314.    difficult to read.
  315.  
  316.  
  317. In general, when a mailing to somebody fails, DON'T post a message
  318. about it!  Think for a moment: you are trying to send something to
  319. someone on ONE system.  Your message might go through (at most) TEN
  320. systems on the way there.  Posting a message in the news sends it to
  321. many thousands of systems throughout the world!  There is no way to
  322. justify adding to the news load of all those machines simply because
  323. you cannot determine how to get your mail through.
  324.  
  325. If your message is important, contact someone who knows more about the
  326. mail system and who might be able to help you get your message
  327. through.  Your local system administrator, for instance, or the admin
  328. of the next site "upstream," might be able to help. You can also send
  329. mail to "postmaster" at one of the major Usenet sites.  Almost all of
  330. these people would rather see an occasional plea for help in their
  331. mailbox than read another broadcast in the news system.  If your
  332. message is *really* important, pick up the phone and try to call the
  333. other person.
  334. --
  335. Gene Spafford
  336. Software Engineering Research Center & Dept. of Computer Sciences
  337. Purdue University, W. Lafayette IN 47907-1398
  338. Internet:  spaf@cs.purdue.edu    phone:  (317) 494-7825
  339. Xref: bloom-picayune.mit.edu comp.protocols.ppp:1106 news.answers:4742
  340. Path: bloom-picayune.mit.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!Germany.EU.net!olymp!ignatios
  341. From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
  342. Newsgroups: comp.protocols.ppp,news.answers
  343. Subject: point-to-point protocol: frequently wanted answers
  344. Summary: This newsgroup contains information about the Internet Point-to-Point
  345.     Protocol, including a bibliography, a list of public domain and
  346.     commercial software and hardware implementations, a section on
  347.     configuration hints and a list of frequently asked ques
  348. Message-ID: <ppp-faq/part1_724965062@cs.uni-bonn.de>
  349. Date: 21 Dec 92 19:13:01 GMT
  350. Expires: Mon, 11 Jan 1993 19:11:02 GMT
  351. Sender: usenet@olymp.informatik.uni-bonn.de
  352. Followup-To: poster
  353. Organization: computer science department, university of Bonn, Germany
  354. Lines: 939
  355. Approved: news-answers-request@MIT.Edu
  356.  
  357. Archive-name: ppp-faq/part1
  358. Version: 2.3
  359. Last-modified: Tue Dec 15 12:34:18 MET 1992
  360.  
  361. 0.1 Introduction
  362.  
  363. I took the Information in Ed Vielmetti's FAQ files, my personal experience,
  364. and lots of stuff from comp.protocols.ppp, and built a new one for them.
  365. This posting will be reposted fortnightly, as soon as it is fairly stable,
  366. and weekly till then. Changed sections are marked in the index with a ! or
  367. + for something got added or - for something got deleted.
  368.  
  369. The major sections start with a ^L, so hit the spacebar on the --more--
  370. prompt.
  371.  
  372. 0.2 Information wanted:
  373.  
  374. If you have experience with anything mentioned here, or know of newer
  375. versions, or of versions of software for other hardware/OS, or ...
  376.  
  377. send me mail. I'll include it and possibly mention your name, if you don't
  378. express otherwise.
  379.  
  380. 1. INDEX TO THE FAQ:
  381.  
  382. 2. What is PPP?
  383.  
  384. 2.1 Introduction
  385. 2.2 PPP features which may or may not be present
  386. 2.3 PPP glossary
  387. 2.4 PPP-relevant RFC's
  388.  
  389. 3.1 How to:
  390. 3.1 connect a single host to a network without needing a new subnet.
  391. 3.2 configure KA9Q PPP and it's Unix counterpart
  392. +3.3 configure NCSA with the merit ppp driver and its unix counterpart
  393. !3.4 work BOOTP over protocols such as SLIP or PPP
  394.  
  395. 4. Real PPP questions with answers
  396. 4.1 Does somebody have a patent on PPP? [no]
  397. 4.2 Is it possible to use PPP as link layer in ISDN? [yes]
  398.  
  399. 5. Free PPP software packages.
  400.  
  401. 5.1 free PPP FOR SunOS 4.1.x:
  402. 5.1.1.1 ppp-1.1.tar.Z, works also on BSD (386BSD: 0.0 only)
  403. 5.1.1.2 pppd-1.01.tar.Z
  404. 5.1.2 dp-2.2.tar.Z
  405. 5.1.3 Perkins/Clements/Fox/Christy PPP for SunOS
  406.  
  407. 5.2 free PPP for BSD:
  408. 5.2.1 ppp-1.1.tar.Z, see 4.1.1.1
  409.  
  410. 5.3 free PPP for SYSVR4:
  411.  
  412. 5.4 FREE PPP FOR MSDOS:
  413.  
  414. 5.4.1 KA9Q NOS ppp additions:
  415. 5.4.2 PPP for NCSA telnet:
  416.  
  417. 5.5 free PPP for AmigaOS:
  418. 5.5.1 AmigaNOS (KA9Q NOS for Amiga):
  419.  
  420. 5.6 free PPP for NeXT:
  421.  
  422. 5.7 free PPP for Macintosh:
  423.  
  424. 6. ftp sites for PPP stuff, docs etc.
  425.  
  426. 7. Commercial PPP software packages.
  427. 7.1 Amiga Inet:
  428. 7.2 Commercial PPP packages for MS-DOS and MS-Windows
  429. +7.2.1 MSDOS with and without MSWindows
  430.  
  431. +7.2.1.1.  LAN WorkPlace for DOS 4.1 beta (see also 7.2.2)
  432. +7.2.1.2.  PC/TCP 2.11
  433. +7.2.1.3.  Distinct TCP/IP 3.0 beta
  434. +7.2.1.4.  Super-PPP for Windows 1.0 beta
  435. !7.2.2 MSDOS/Novell:
  436.  
  437. -7.3 for other computers:
  438.  
  439. 8. PPP hardware.
  440. 8.1 Hardware that does async PPP
  441. 8.2 Hardware that supports sync PPP
  442. 8.3 Recent summaries stuff from the net, will be merged with the rest later
  443.  
  444. +9. (incomplete) Acknowledgements
  445.  
  446. 2. What is PPP?
  447.  
  448. 2.1 Introduction
  449. PPP is the Internet Standard for transmission of IP packets over serial
  450. lines. PPP supports async and sync lines. For a general discussion of PPP,
  451. and of the PPP vs. SLIP question, look at the paper
  452.  
  453. ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z
  454.  
  455. 2.2 PPP features which may or may not be present
  456.  
  457. Above and beyond compatibility with basic PPP framing, note whether
  458. the software implements the following features.  Not all features are
  459. needed or even desired in every product.
  460.  
  461. - "demand-dial".  Bring up a PPP interface and dial the phone when
  462.   packets are queued for delivery; bring the interface down after some
  463.   period of inactivity.
  464.  
  465. - "redial".  (For lack of a better term).  Bring up a PPP
  466.   interface whenever it goes down, to keep a line up.
  467.  
  468. - "scripting".  Negotiate through a series of prompts or intermediate
  469.   connections to bring up a PPP link, much like the sequence of events
  470.   used to bring up a UUCP link.
  471.  
  472. - "parallel".  Configure several PPP lines to the same destination and
  473.   do load sharing between them.  (Not standardized, usually only see
  474.   in SLIP implementations, noted there as "parallel-slip".)
  475.  
  476. - "filtering".  Select which packets to send down a link or whether to
  477.   bring up a "demand-dial" link based on IP or TCP packet type or TOS,
  478.   e.g. don't dial the phone for ICMP ping packets.
  479.  
  480. - "header compression".  TCP header compression according to RFC 1144.
  481.   Marginally useful on high speed lines, essential for low speed lines.
  482.  
  483. - "server".  Accept incoming PPP connections, which might well also
  484.   include doing the right things with routing.
  485.  
  486. - "tunneling". build a virtual network over a PPP link across a TCP stream
  487.    through an existing IP network
  488.  
  489. - "extra escaping". byte-stuffing characters outside the negotiated
  490.   asyncmap, configurable in advance but not negotiable
  491.  
  492. 2.3 PPP glossary
  493.  
  494. From: emv@msen.com (Edward Vielmetti) [and others]
  495. Subject: PPP glossary
  496.  
  497. Every new technology breeds its own set of acronyms.  PPP is no
  498. different.  Here is a glossary of sorts.
  499.     
  500. ack    Acknowledgement.
  501. AO    Active open [state diagram] (no lonter part of the FSM as of RFC 1331)
  502. C    Close [state diagram]
  503. CHAP    Challenge-Handshake Authentication Protocol (RFC 1334)
  504. D    Lower layer down [state diagram]
  505. DES    Data Encryption Standard
  506. DNA    Digital Network Architecture
  507. IETF    Internet Engineering Task Force.
  508. IP    Internet Protocol
  509. IPCP    IP Control Protocol.
  510. IPX    Internetwork Packet Exchange (Novell's networking stack)
  511. FCS    Frame Check Sequence [X.25]
  512. LCP    Link Control Protcol.
  513. LQR    Link Quality Report.
  514. MD4    MD4 digital signature algorithm
  515. MD5    MD5 digital signature algorithm
  516. MRU    Maximum Receive Unit
  517. MTU    Maximum Transmission Unit
  518. nak    Negative Acknowledgement
  519. NCP    Network Control Protocol.
  520. NRZ    Non-Return to Zero bit encoding. (SYNC ppp default because of
  521.     availability)
  522. NRZI    Non-Return to Zero Inverted bit encoding. (SYNC ppp preferred
  523.     alternative to NRZ)
  524. OSI    Open Systems Interconnect
  525. PAP    Password Authentication Protocol (RFC 1334)
  526. PDU    Protocol Data Unit (i.e., packet)
  527. PO    Passive open [no longer part of state diagram]
  528. PPP    Point to Point Protocol (RFC 1331, 1332, 1333, 1334, 1376, 1377, 1378)
  529. RCA    Receive Configure-Ack [state diagram]
  530. RCJ    Receive Code-Reject [state diagram]
  531. RCN    Receive Configure-Nak or -Reject [state diagram]
  532. RCR+    Receive good Configure-Request [state diagram]
  533. RER    Receive Echo-Request [no longer part of state diagram]
  534. RFC    Request for Comments (internet standard)
  535. RTA    Receive Terminate-Ack [state diagram]
  536. RTR    Receive Terminate-Request [state diagram]
  537. RUC    Receive unknown code [state diagram]
  538. sca    Send Configure-Ack [state diagram]
  539. scj    Send Code-Reject [state diagram]
  540. scn    Send Configure-Nak or -Reject [state diagram]
  541. scr    Send Configure-Request [state diagram]
  542. ser    Send Echo-Reply [no longer part of state diagram]
  543. sta    Send Terminate-Ack [state diagram]
  544. str    Send Terminate-Request [state diagram]
  545. ST-II    Stream Protocol
  546. TO+    Timeout with counter > 0 [state diagram]
  547. TO-    Timeout with counter expired [state diagram]
  548. VJ    Van Jacobson (RFC 1144 header compression algorithm)
  549. XNS    Xerox Network Services
  550.  
  551. 2.4 PPP relevant RFC's:
  552.  
  553. Here's a list with descriptions.  Note some of these are obsolete.
  554.  
  555. 1378  PPP AppleTalk Control Protocol (ATCP). Parker, B.  1992 November; 16 p.
  556.       (Format: TXT=28496 bytes)
  557.  
  558. 1377  PPP OSI Network Layer Control Protocol (OSINLCP). Katz, D.  1992
  559.       November; 10 p. (Format: TXT=22109 bytes)
  560.  
  561. 1376  PPP DECnet Phase IV Control Protocol (DNCP). Senum, S.J.  1992 November;
  562.       6 p. (Format: TXT=12448 bytes)
  563.  
  564. 1334  PPP authentication protocols. Lloyd, B.; Simpson, W.A.  1992 October;
  565.       16 p. (Format: TXT=33248 bytes)
  566.  
  567. 1333  PPP link quality monitoring. Simpson, W.A.  1992 May; 15 p. (Format:
  568.       TXT=29965 bytes)
  569.  
  570. 1332  PPP Internet Protocol Control Protocol (IPCP). McGregor, G.  1992 May;
  571.       12 p. (Format: TXT=17613 bytes)  (Obsoletes RFC 1172)
  572.  
  573. 1331  Point-to-Point Protocol (PPP) for the transmission of multi-protocol
  574.       datagrams over point-to-point links. Simpson, W.A.  1992 May; 66 p.
  575.       (Format: TXT=129892 bytes)  (Obsoletes RFC 1171, RFC 1172)
  576.  
  577. 1220  Point-to-Point Protocol extensions for bridging. Baker, F.,ed.  1991
  578.       April; 18 p. (Format: TXT=38165 bytes)
  579.  
  580. 1172  Point-to-Point Protocol (PPP) initial configuration options. Perkins,
  581.       D.; Hobby, R.  1990 July; 38 p. (Format: TXT=76132 bytes)  (Obsoleted by
  582.       RFC 1331, RFC 1332)
  583.  
  584. 1171  Point-to-Point Protocol for the transmission of multi-protocol datagrams
  585.       over Point-to-Point links. Perkins, D.  1990 July; 48 p. (Format:
  586.       TXT=92321 bytes)  (Obsoletes RFC 1134; Obsoleted by RFC 1331)
  587.  
  588. 1134  Point-to-Point Protocol: A proposal for multi-protocol transmission of
  589.       datagrams over Point-to-Point links. Perkins, D.  1989 November; 38 p.
  590.       (Format: TXT=87352 bytes)  (Obsoleted by RFC 1171)
  591.  
  592.  
  593. bob@MorningStar.Com (Bob Sutterfield) wrote in comp.protocols.ppp
  594. (Message-ID: <BOB.92Dec3145948@volitans.MorningStar.Com>):
  595.  
  596. All of 1134, 1171, and 1172 (and 1055, for that matter :-) have been
  597. obsoleted.  They're interesting only if you want to debug a connection
  598. with an ancient PPP implementation, and you're wondering why (e.g.) it
  599. asked you for IPCP option 2 with a length of only 4, and
  600. Compression-Type 0x0037.
  601.  
  602. (There's a lot of that still running around - be careful out there.)
  603.  
  604.  
  605. 3. HOW TO ... :
  606.  
  607. 3.0 complain about missing or incorrect information in the FAQ list
  608.  
  609. E-mail to ignatios@cs.uni-bonn.de (Ignatios Souvatzis), and add
  610. information I'll need to think about it. That is:
  611.  
  612. - In case of incorrect information, send me the correct information and the
  613.    source of it.
  614.  
  615. - In case of missing information, send me the information which is missing and
  616.   the source of it.
  617.  
  618. 3.1 connect a single host to a network without needing a new subnet.
  619.  
  620. From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis)
  621.  
  622. If you have only one single machine on the other side, the easiest way
  623. is to give it a IP address belonging to the local ethernet/IP subnet,
  624. and to tell the ppp gateway machine to advertise (proxy arp) its own
  625. ethernet address as the other machines'. Works like a charm here. Of
  626. course, for a large group or complicated network on the other side,
  627. you would get more management problems.
  628.  
  629. On the gateway do:
  630.  
  631. arp -s othermachinesipaddress myownethernetaddress permanent public
  632. ifconfig pppNUMBER myipaddress othermachinesipaddress [other params] up
  633.  
  634. on remote machine:
  635.  
  636. ifconfig pppNUMBER gatewaysipaddress [other params] up
  637. route add default gatewaysipaddress 1
  638.  
  639. pppNUMBER might be spelled as dpNUMBER for dialup IP.
  640.  
  641. Of course, if you use routeing daemons, you could also propagate the
  642. route via routed / gated etc. to other machines, but it's more painful
  643. because every machine has to do it (and might choose not to do it),
  644. and every machine doing IP on a Ethernet HAS to talk arp.
  645.  
  646. On intermittently connected demand-dialed links, you may need to edit
  647. /etc/gateways to define the destination of the PPP or SLIP connection
  648. as a "passive" link.  Otherwise, routed will remove routes from the
  649. kernel's routing table that use that link, because it won't hear RIPs
  650. coming from hosts or routers across the wire.  Since it doesn't hear
  651. anything from hosts or routers on the far side of the wire, routed
  652. assumes that the link is dead forever.
  653.  
  654.  
  655. 3.2 configure KA9Q PPP and it's Unix counterpart
  656.  
  657. Newsgroups: comp.protocols.ppp
  658. From: kim@MorningStar.Com (Kim Toms)
  659. Subject: Re: PPP for DOS? (good info for FAQ)
  660. Date: Wed, 9 Dec 1992 06:26:28 GMT
  661.  
  662. I have been able to use the ka9q software on my PC to call my Suns at
  663. work.  This is available from merit.edu:/pub/ppp/ka9q.zip. I had to
  664. tell our Sun product [that would be Morningstar PPP, see below. I.S.]
  665. "nolqm" in order to prevent it from hanging up because of an lqm
  666. failure, but other than that, I have had no trouble.
  667.